A common problem facing organizations with large enterprise networks is the problem of asymmetric routing. Such a situation can occur in a variety of contexts, but often occurs where an enterprise obtains Internet connectivity from multiple Internet Service Providers (ISPs); in other words, when the enterprise has multiple address prefixes.
Refer, for example, to FIG. 1. This illustration depicts a multi-ISP environment 10 in which an enterprise network includes two proxy devices P1 and P2, which provide connectivity for a client 12 to a server 14 via two ISPs 16 and 18, respectively. Of course, this illustration depicts a rather straightforward routing path (from P1 through router R1, and from R3 through P2 and R2) for each ISP connection, whereas in other deployment scenarios the routing paths may be more complex. In any such deployment, however, the different proxy devices are likely to reside on different network segments 20, 22. This poses a problem when the proxies employ client IP spoofing.
With client IP spoofing, once a connection from the client 12 to proxy P1 is intercepted and terminated, the outbound connection from P1 to server 14 will carry the client's IP address. As such, the return traffic could traverse a completely different path (e.g., through ISP 18, router R2, proxy P2 and router R3) than was traversed by the forward direction traffic. Indeed, the return traffic path will depend entirely on the configuration at the node to which the outbound connection is destined (i.e., server 14). Consequently the return traffic may not reach the proxy that intercepted the original request.
When proxy P2 receives the return traffic from server 14, it will have no connection reference with which to associate that traffic. That is, P2 will not have any state information concerning the connection for which the traffic from the server is intended. Consequently, P2 will not forward the traffic to the requesting client 12 and, instead, is likely to reject it because a proxy that is acting as a security device must be conservative regarding the types of traffic to be allowed through. Moreover, when proxy P1 (as well as client 12) fails to receive anything from the server 14, these outbound connections may eventually timeout because no return traffic will have been received.
Depending on the enterprise network configuration, asymmetric routing may occur on the inbound connections (from the server to the client) as well as on the outbound connections (from the client to the server). In such a case, traffic originated by a particular client may not reach a proxy device that was intercepting traffic from a server. This would, again, trigger incorrect connection resets. What is needed is a solution for such asymmetric routing situations.